A communication protocol may exist at several levels in a communication system and may be defined as a set of rules that end points in the communication system utilize when they communicate. The set of rules for the communication protocol may be described in a particular standard. There are many different existing and developing communication protocols. It may be desirable to perform tests of such existing communication protocols and developing communication protocols at various phases during the development cycle of the communication protocol. Such tests may include conformance tests and system integration tests on a communication system utilizing the communication protocol.
Conventional tests may be designed for a particular communication protocol or communication system and may be focused on a particular problem to be tested. Hence, test developers must develop new tests for different communication protocols or communication systems. In addition, conventional test tools do not provide mechanisms to allow the protocol to define its testing interface. In this environment, detailed tests are either not done or done by manipulating the code of the communication protocol.
Conventional tests also have no control over the complex interactions that occur in a protocol stack. Thus, they cannot create the test condition necessary to test particular aspects of the communication protocol. For example, some communication protocols may parse data into smaller portions or packets for more efficient routing. Each packet may include a sequenced number from a counter in a header of the packet. The receiver may compare the sequenced number of the transmitted packet with an expected value to make sure a message is ordered. The counter may start counting at an initial count value and increment its count by one for each transferred packet and “wrap” back to its initial count value after the counter reaches its maximum count value. The counter may be as large as 64 bits in size for some newer communication protocols. A conventional test to test the wrap condition may start the counter at the initial count value and transfer sufficient packets so the counter will wrap back to its initial count value. This can take a considerable time especially with counters increasing in size. Therefore, testing such a “wrap condition” with a conventional testing system is likely not done or tested by requiring that developers modify the source code of the communication protocol to create the “wrap condition.” Both situations are undesirable.
Although the following Detailed Description will proceed with reference being made to illustrative embodiments, many alternatives, modifications, and variations thereof will be apparent to those skilled in the art. Accordingly, it is intended that the claimed subject matter be viewed broadly.